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(57) Abstract: In general, in one post aspect, the disclosure describes a method for use in providing access to network resources. 
The method includes receiving at a first server from a remote client, a message identifying a network resource. 'I"he method also 
includes determining authorization information associated with the user or the group and sending the authorization information, in 
accordance with the authorization scheme, to the second server. 
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NETWORK RESOURCE ACCESS 

Background 

Networks, such as the Internet, provide users access to a wide variety of resources, 
tt 

5 These resources include documents, such as analyst reports and technical white papers, and 
other electronic content, such as audio and video. 

In technical terms, these resources are provided by network servers. Servers receive 
requests for resources from clients and send the requested resource in response. Often 
network servers protect resources from unauthorized access. For example, many servers 
10 require a user to correctly enter a username and password before authorizing access. A 

username/password scheme is one of a variety of authentication mechanisms that enables a 
server to restrict access to particular users. 

Different servers may use different authorization schemes. Additionally, even those 
servers that use the same kind of authorization scheme may request different information 
15 from a user. For example, a user's username and password may be different for different 
servers. Thus, as a user "surfs" to different network servers, the user often needs to 
remember and re-enter their authorization data. 
Summary 

In general, in one aspect, the disclosure describes a method for use in providing 
20 access to network resources. The method includes receiving, at a first server from a remote 
client, a message identifying a network resource, the message being associated with a user 
or group, the resource being protected by an authorization scheme provided by a second 
server. The method further includes determining authorization information associated with 
the user or the group and sending the authorization information, in accordance with the 
25 authorization scheme, to the second server. 

Embodiments may include one or more of the following features. The method may 
include transmitting instructions for processing by the client that cause the client to transmit 
the authorization information to the second server. The method may also include 
determining that the authorization information sent to the second server by the first server 
30 results in authorization. The instructions may be in JavaScript. The authorization 
information associated with the user may include a usemame and a password for the 
authorization scheme provided by the second server. The method may include storing 
authorization information for different users. The method may include determining the 
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authorization scheme provided by the second computer. The method may include storing 
information identifying the different authorization schemes provided by different respective 
servers. The method may include sending the information to the second server within an 
HTTP (HyperText Transfer Protocol) GET or POST message. The network may be an 
5 intranet or the Internet The network resource may be a document The method may 

include sending an abstract of the network resource to the client. The message identifying a 
network resource may be a message generated in response to user selection of the abstract. 

. In general, in another aspect, the disclosure describes a computer program product, 
disposed on a computer readable medium, for use in providing access to network resources. 

1 0 The program includes instructions for causing a processor to receive, at a first server from a 
remote client, a message identifying a network resource, the message being associated with 
a user or group, the resource being protected by an authorization scheme provided by a 
second server. The program also includes instructions that determine authorization 
information associated with the user or the group of users and send the authorization 

15 information, in accordance with the authorization scheme, to the second server. 

In general, in another aspect, the disclosure describes a method for authorizing a 
user attempting to access a document over the Internet. The method includes storing 
authorization information for different users, storing information identifying the different 
authorization schemes used by different respective servers, sending an abstract of a 

20 document to a web browser client, receiving, at a first server from the web browser client, a 
message identifying the document, the message being associated with the user, the 
document being protected by an authorization scheme provided by a second server, 
determining authorization information associated with the user, the authorization 
information including a username and a password, determining the authorization scheme 

25 provided by the second server, sending the authorization information, in accordance with 
the authentication scheme, to the second server, determining that the authorization 
information sent to the second server successfully authorized access, and transmitting 
instructions to the client, the instructions for causing the client to transmit the authorization 
information to the second server. 

30 In general, in another aspect, the disclosure describes a system for providing access 

to network resources served by different network servers. The system includes storage 
configured to store authorization information for different servers and/or resources for 
different users and/or groups of users. The system also includes instructions for causing a 
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system processor to receive, at a first server from a remote client, a message identifying a 
network resource, the message being associated with a user or group of users, the resource 
being protected by an authorization scheme provided by a second server. The instructions 
also cause the processor to determine authorization information associated with the user or 
5 the group of users from the storage of authorization information, and send the authorization 
information, in accordance with the authorization scheme, to the second server. . 

In general, in another aspect, the disclosure describes a method for use in providing 
access to network resources. The method includes receiving, at a first server from a remote 
client, a message identifying a network resource, the message being associated with a user 
10 or group of users, the resource being protected by an authorization scheme provided by a 
second server. The method also includes determining authorization information associated 
with the user or the group of users, and transmitting instructions for processing by the 
client, the instructions for causing the client to transmit the authorization information to the 
second server. 
15 Brief Description of the Drawings 

FIGs. 1 to 10 are diagrams that illustrate operation of a system for providing access 
to network resources. 

FIG. 1 1 is a diagram of a system for use in providing access to network resources. 

FIG. 12 is a flow-chart of a process for use in providing access to network 
20 resources. 

Detailed Description 

FIGs. 1 depicts resources 106 stored on different network servers 102. As shown, 
the servers 102 protect the resources 106 from unauthorized access using authorization 
schemes 104. These authorization schemes 104 may vary in the techniques they use to 
25 authorize access to die resources 106 and may also vary in the data they collect to provide 
authorization. 

Described herein is an approach that takes care of server authorization for a user 
'^behind the scenes". In this scheme, a server 110 can automatically handle aspects of 
authorization on behalf of a user. This can potentially free the user to access resources 106 
30 provided by different servers 110 without repeatedly entering their authorization data into 
server forms. The server 110 can support many different servers 102 providing resources 
and can support many different users. 
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In greater detail, FIG. 1 shows a client 100 connected to a network 108. The client 
100 may be a browser (e.g., Microsoft Explorer) that sends requests for network resources 
106 provided by different Internet or intranet servers 102. These requests may be HTTP 
(HyperText Transfer Protocol) messages that identify a resource 106 using a URL 
5 (Universal Resource Locator). For example, a request for a document from the New York 
Times web server may be "HTTP GET www.nytimes.com/headlines.htmr where the string 
"wwwjoiytimes.coni/headlmes.html" is the URL specifying the desired resource. 

FIG. 1 also shows a server 110 that can coordinate access to the servers' 102 
resources 106. The server 110 includes a web server 116 (e.g., an Apache web server) that 
10 responds to received HTTP messages. The server 110 also includes authorization 
instructions 1 12 that can negotiate authorization with different servers 102 for a user 
operating a client 100. 

To illustrate how the approach can be used to provide client 100 access to resources 
106, FIGs. 2-10 depict an example of operation of an authorization system. In this 
15 example, server 110 performs a "test" negotiation of authorization with a server 102 

protecting a resource 102 of interest to a user. This test can determine whether the user is 
authorized to access the requested resource. After this test, the server 110 can transmit 
information to the client 100 so that the client 100 can repeat the authorization negotiation 
and establish an independent session with the server 102. This approach enables the server 
20 1 10 to coordinate authorization without necessitating further involvement with a session 
that ensues between the client 100 and the server 104. This ,r handing off 1 of the session to 
the client 100, however, is merely optional. That is, server 1 10 may act as a proxy after 
initially negotiating authorization. 

In the sample shown in FIG. 2, the server 110 stores abstracts 1 14 of resources 106. 
25 Such abstracts may include text descriptions of the resource 1 06 and/or other information 
(e.g., thumbnails of images or sound clips). The web server 116 may provide web pages 
that permit a user to specify a search of the abstracts and display a list of abstracts relevant 
to the query. For example, as shown in FIG. 2, a user operates the client 100 to request 120 
an abstract 1 14 for a particular resource. As shown in FIG. 3, the server 1 10 responds by 
30 sending a message 122 to the client 100 that includes the abstract for presentation to the 
user. 

After viewing the abstract, the user may indicate they would like to receive the 
resource 106d described by the abstract For example, a user may select a "View 
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document" button displayed by a web page provided by the server 110. As shown, in FIG. 
4, selection can cause the client 100 to send a request 124 for the resource to the server 110. 
Upon receipt of the request 124, the server 110 may determine the identity of a user if this 
has not been done previously. For example, the server 110 may interactively collect user 
5 information (e.g., username and password) via fields in a web page or non-interactively by 
collecting a "cookie" stored by client 100. This authorization process with server 110 can 
permit the server 1 10 to determine the authorization information associated with a 
particular user or group of users. Thereafter, the server 110 can provide authorization for 
resources 106 provided by servers 102 without further user participation in the 

10 authorization schemes 104 used by the servers 102. 

As shown in FIG. 5, the server 110 determines authorization information associated 
with the user that can be used to gain access to the resource. For example, the server 110 
can determine the server 102b that provides the requested resource 106d (e.g., by parsing 
the request message 124 of FIG. 4) and lookup the user's username and password for the 

15 server 102b in a database. After retrieving the authorization information, the server 110 can 
negotiate authorization on behalf of the user by assembling the authorization information 
into a structure compliant with the authorization scheme provided by the server 102b 
storing the requested resource 106d. The server 110 can then transmit the assembled 
information in accordance with the server 102b authorization scheme(s) 104b. The 

20 transmitted information can simulate a form submission process. For example, an HTTP 
GET message assembled for transmission to the server 102b can include a request for a 
URL of "www.server.com/document.doc?username=guest; password=rosebud" . Other 
authorization schemes, however, will expect the authorization information to be encoded 
differently (e.g., as an HTTP POST message). 

25 As shown in FIG. 6, the server 102b receiving the authorization information can 

return an indication 128 that authorization to access the resource has been granted. For 
example, such an indication may be as simple as an HTTP "OK" message. The server 110 
can parse the received message 128 to determine whether or not the server 102b has 
authorized access. 

30 As shown in FIG. 7, after determining authorization has been granted, the server 

1 10 can transmit information 130 to the client 100 that enables the client 100 to 
independently initiate a session with the server 104. For example, the server 110 may send 
the client 100 instructions (e.g., JavaScript) that the client 100 can interpret or execute to 



-5- 



WO 02/091648 



PCT/US02/13860 



establish authorized access to the resource. The instructions can repeat the authorization 
negotiation successfully tested by the server 1 10. Thus, as shown* the client 100 sends a 
request 132 for authorization (FIG. 8), receives authorization 134 (FIG. 9), and ultimately 
receives the resource 106d of interest (FIG. 10). 
5 Once a session is established between the client 100 and the server 102b providing 

the resource 106d, reauthorization need not be repeated unless required by the server 102b. 
That is, typically, a client 100 will establish a session only once with a server in a given 
time period even though the client 100 may access different resources 106 served by the 
server 102b. 

10 FIGs. 2-10 depict sample operation of an example system. However, other systems 

need not proceed as described above. For example, the server 110 need not "test" 
authorization before sending the authorization instructions 130 to the client 100. 
Additionally, as described above, the server 110 need not transmit authorization 
instructions 130 at all, but may instead act as a "go between" between the client 100 and the 

1 5 server 1 02d protecting the resources 1 06d of interest after initially negotiating 
authorization. 

FIG. 1 1 depicts a sample architecture of an authorization system 112 (e.g., 1 12 in 
FIGs. 1-10). As shown the system 1 12 includes a database (e.g., a MySQL relational 
database) that stores authorization information 146 for different users at different servers. 

20 For example, as shown, a user "rob@bitpipe.com" can use a username of "Rob" and a 
password of "007" to access resources from ServerA and a username of "guest" and a 
password of "guest" to access resources from ServerB. After detennining the server storing 
a requested resource, authorization instructions 140 can retrieve the appropriate 
authorization information for a user. The data 146 may include a username and password, 

25 as shown, and/or other credentials. The data 146 may include entries for different users or 
groups of users. By providing a "group" capability, a user can gain access to many 
different servers 102 without explicitly registering. That is, a new member of a group can 
access those servers 102 already having defined authorization information. 

As shown, the database also includes data 144 identifying the authorization scheme 

30 used by a server. For example, as shown, ServerA uses an HTTP GET encoding scheme, 
ServerB uses an HTTP POST encoding scheme, while ServerC uses a technique known as 
Basic Authorization. By changing these entries, the server 1 10 can quickly adapt should a 
server change its authorization scheme. 
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The database also includes modules of instructions 142 that control how to negotiate 
authorization with the server storing a resource of interest These instructions 142 can 
access and assemble authorization information and handle communication with the server 
storing a desired resource. For example, based on the type of authorization scheme 144 
5 identified for a given server, the instructions 142 can negotiate access to a server using the 
user's authorization information 146. The system 1 12 can then package instructions for 
transmission to the client 100 so that the client can repeat the proven-successful negotiation. 

FIG. 12 depicts a flow-chart of the process 150 described above. As shown, after a 
server receives 152 a user request for access to a resource provided by a different server, the 

1 0 server retrieves 154 authorization information for the user (e.g., by retrieving data from data 
146) and identifies 156 the type of authorization scheme used by the server providing the 
resource (e.g., by retrieving data from data 144). After successfully negotiating 158 
authorization with the server, the process 150 transmits 160 instructions to the client that 
cause the client to negotiate authorization. 

1 5 The above described a sample implementation. However, there are a wide variety 

of variations of the above. For example, while depicted as separate entities, the 
authorization instructions 1 12 may be integrated into the web server 116. Additionally, 
while the above describes a division between the access module instructions and the 
database of authorization schemes, other implementations may include different 

20 configurations. For example, the access modules may be hfird-coded for the authorization 
scheme provided by a server 102. 

The techniques described herein may find applicability in many computing or 
processing environments. The techniques may be implemented in hardware or software, or 
a combination of the two. Preferably, the techniques are implemented in computer 

25 programs executing on programmable computers that each include a processor, a storage 
medium readable by the processor (including volatile and non-volatile memory and/or 
storage elements), at least one input device, and one or more output devices. 

Each program is preferably implemented in high level procedural or object oriented 
programming language to communicate with a computer system. However, the programs 

30 can be implemented in assembly or machine language, if desired. In any case the language 
may be compiled or interpreted language. 

The computer program(s) are preferably stored on a storage medium or device (e.g., 
CD-ROM, hard disk, or magnetic disk) that is readable by a general or special purpose 
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programmable computer for configuring and operating the computer when the storage 
medium or device is read by the computer to perform (he procedures described herein. The 
system may also be considered to be implemented as a computer-readable storage medium, 
configured with a computer program, where the storage medium so configured causes a 
5 computer to operate in a specific and predefined manner. 

Other embodiments are within the scope of the following claims. 
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What is claimed is: 

1 . A method for use in providing access to network resources* the method comprising: 
receiving, at a first server from a remote client, a message identifying a network 

resource, the message being associated with a user or group, the resource being protected 
5 by an authorization scheme provided by a second server; 

determining authorization information associated with the user or the group; and 
sending the authorization information, in accordance with the authorization scheme, 
to the second server. 

2. The method of claim 1, further comprising transmitting instructions for processing 
10 by the client, the instructions for causing the client to transmit the authorization information 

to the second server. 

3. The method of claim 2, further comprising determining that the authorization 
information sent to the second server by the first server results in authorization. 

4. The method of claim 2, wherein the instructions comprise JavaScript 

15 5. The method of claim 1, wherein the authorization information associated with the 
user comprises a username and a password for the authorization scheme provided by the 
second server. 

6. The method of claim 1, further comprising storing authorization information for 
different users. 

20 7. The method of claim 1, further comprising determining the authorization scheme 
provided by the second computer. 

8. The method of claim 7, further comprising storing information identifying the 
different authorization schemes used by different respective servers. 

9. The method of claim 8, wherein the sending the information to the second server 
25 comprises sending the information within an HTTP (HyperText Transfer Protocol) GET or 

POST message. 

10. The method of claim 1, wherein the network comprises at least one of the following: 
an intranet and the Internet. 

1 1 . The method of claim 1 , wherein the network resource comprises a document 
30 12. The method of claim 1 , further comprising sending an abstract of the network 

resource to the client 

13. The method of claim 12, wherein the message identifying a network resource 
comprises a message generated in response to user selection of the abstract 
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14. A computer program product, disposed on a computer readable medium, for use in 
providing access to network resources, the program including instructions for causing a 
processor to: 

receive, at a first server from a remote client, a message identifying a network 
5 resource, the message being associated with a user or group, the resource being protected 
by an authorization scheme provided by a second server; 

determine authorization information associated with die user or the group of users; 

and 

send the authorization information, in accordance with the authorization scheme, to 
10 the second server. 

15. The program of claim 14, further comprising instructions for causing the processor 
to transmit instructions for processing by the client, the transmitted instructions for causing 
the client to transmit the authorization information to the second server. 

16. The program of claim 15, further comprising instructions for causing the processor 
15 to determine that the authorization information sent to the second server by the first server 

results in authorization. 

17. The program of claim 15, wherein the transmitted instructions comprise JavaScript. 

1 8. The program of claim 14, wherein the authorization information associated with the 
user comprises a username and a password for the authorization scheme provided by the 

20 second server. 

19. The program of claim 14, further comprising instructions for causing the processor 
to store authorization information for different users. 

20. The program of claim 14, further comprising instructions for causing the processor 
to determine the authorization scheme provided by the second computer. 

25 21. The program of claim 14, further comprising instructions for causing the processor 
to store information identifying the different authorization schemes used by different 
respective servers. 

22. The program of claim 14, wherein the instructions for causing the processor to send 
the information to the second server comprise instructions that cause the processor to send 

30 the information within an HTTP (HyperText Transfer Protocol) GET or HTTP POST 
message. 

23. A method for authorizing a user attempting to access a document over the Internet, 
the method comprising: 
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storing authorization information for different users; 

storing information identifying the different authorization schemes used by different 
respective servers; 

sending an abstract of a document to a web browser client; 
5 receiving, at a first server from the web browser client, a message identifying the 

document, the message being associated with the user, the document being protected by an 
authorization scheme provided by a second server; 

detennining authorization information associated with the user, the authorization 
information including a username and a password; 
10 determining the authorization scheme provided by the second server; 

sending the authorization information, in accordance with the authentication 
scheme, to the second server; 

determining that the authorization information sent to the second server successfully 
authorized access; and 

1 5 transmitting instructions to the client, the instructions for causing the client to 

transmit the authorization information to the second server. 

24. A system for providing access to network resources served by different network 
servers, the system comprising: 

storage configured to store authorization information for different servers and/or 
20 resources for different users and/or groups of users; and 

instructions for causing a system processor to 

receive, at a first server from a remote client, a message identifying a network 
resource, the message being associated with a user or group of users, the resource being 
protected by an authorization scheme provided by a second server; 
25 determine authorization information associated with the user or the group of users 

from the storage of authorization information; and 

send the authorization information, in accordance with the authorization scheme, to 
the second server. 

26. A method for use in providing access to network resources, the method comprising: 
30 receiving, at a first server from a remote client, a message identifying a network 

resource, the message being associated with a user or group of users, the resource being 
protected by an authorization scheme provided by a second server; 
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determining authorization information associated with the user or the group of 
users; and 

transmitting instructions for processing by the client, the instructions for causing the 
client to transmit the authorization information to the second server. 

27. The method of claim 26, further comprising sending the authorization information, 
in accordance with the authorization scheme, to the second server. 

28. The method of claim 26, wherein the instructions comprise JavaScript 

29. The method of claim 26, wherein the authorization information associated with the 
user comprises a username and a password for the authorization scheme provided by the 
second server. 

30. The method of claim 26, further comprising storing authorization information for 
different users. 

3 1 . The method of claim 26, further comprising determining the authorization scheme 
provided by the second computer. 

32. The method of claim 31 , further comprising storing information identifying the 
different authorization schemes used by different respective servers. 
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